cc @jtratner

I had to create a core.index.identical method (similar to .equals) but also compares attributes (e.g. name)

we don't have anything like this, right?

do you know python calls for x is y test? (aside from __eq__ or is that it?

There's an issue for that isn't there? Comparing indexes including meta data

prob is
can u link if there is (what I did prob wont solve it)

could only find #3317, with a just passing mention....should i open a new issue for it? really just a decision....i remember preserving name broke a few tests. can't remember if it was a bunch or just a few though...i might have it in a branch

x is y tests for object identity, so it won't call any methods on the object. It's not (and shouldn't be) guaranteed that Index will remain the same object after transformations, even though it doesn't require copying any of the index attributes.

Example of is checks:

lst = [1, 2, 3]
lst2 = list(lst)
assert not (lst is lst2)

You could potentially add a np.may_share_memory check (but only for non-MultiIndex).

I'm not totally clear on what you're looking for here. I don't think it's a good idea to have identical test for object identity (though, granted, there is some overhead with views of MultiIndex, but not much [approx space complexity O(n+m) where n and m are length of the set of levels and length of the set of labels]).

I'm wrong on space complexity of MI view - it's whatever space python needs to make a list pointing to all the lists of levels and a list pointing to all the lists of labels. (so a MI with 2 sets of levels and 2 lists of labels costs two lists of length 2 to shallow copy) very minimal.

@jtratner

its just a very simple issue

if you are reindexing with an index that is identical (and copy is not set), then just return the object

but this HAS to account for an equals index, but with a different name for example
(which relates to the semi-mutable index)

makes sense?

In [6]: index = pd.Index(list(range(5)))

In [7]: index2 = pd.Index(list(range(5))).copy(name='foo')

In [8]: index.equals(index)
Out[8]: True

In [9]: index.identical(index)
Out[9]: True

In [10]: index.identical(index2)
Out[10]: False

In [11]: index.equals(index2)
Out[11]: True

In [12]: index.identical(index2)
Out[12]: False

In [13]: df = DataFrame(randn(5,2),index=index)

In [17]: df.reindex(index2).index.identical(index2)
Out[17]: True

In [18]: df.reindex(index2).index.equals(index2)
Out[18]: True

In [20]: df.reindex(index2).index.identical(index)
Out[20]: False

In [21]: df.reindex(index2).index.equals(index)
Out[21]: True

Does identical also test the freq attribute of the appropriate indexes?

yep freq/tz on datetime index, freq on period

on MI, levels are already tested (and I think labels) via equals, so it just tests name,

👍

what if identical replaces __eq__ ?

so all current code will work, but then true equality is tested by index == index2 or is that confusing?

that will break tests... plus that might be kind of a nasty surprise to people who don't religiously keep track of tz and freq

fair enough...

for the record i would like that, but too much back-incompat. would actually fix #3317 i believe

Oh okay, I wasn't totally clear on your question. Looks good :)

@jtratner @cpcloud pls give this a once over..thxs

Will look over in a minute.

@jreback this doesn't quite work for MultiIndex yet. Is it supposed to?

E.g.

mi = pd.util.testing.makeCustomDataframe(5, 5).stack().index
assert mi.identical(mi)
other = mi.from_tuples(tuple(mi))
assert not mi.identical(other), "Failed - other does not have same names"

On a related note - for some reason, MultIIndex appears to have a name attribute that returns None, which shadows the issue. (i.e., continuing previous)

In [16]: print(mi.name)
None

In [17]: print(mi.names)
FrozenList([u'R0', u'C0'])

In [18]: print(other.name)
None

In [19]: print(other.names)
FrozenList([None, None])

Ah, it's because Index sets name=None explicitly. Is it worth adding a property to MultiIndex to mi.name fail?

I think there is prob some compatibility going on here

iow you need to know whether an object is an index or mi and then use name or names

@jtratner side issue - rename in index is broken for MultiIndex, and need some tests...thanks

@jreback the real problem is that rename and name should not exist for MultiIndex (they only make sense for Index objects).

That said, why can't you just set _comparables = ['names']?

rename does makes sense for MI, e.g.

mi.set_names(['level_0','level_1'])

?

@jtratner oh I did do that, I was trying to use rename in some tests; it breaks for MI....that's all (you can just use set_names, but the arguments are only built for a single name), and the rename for an Index should be able to take a list of a scalar (e.g. i.rename('foo') doesn't work, but i.rename(['foo']) does...(I know its a convenience function)....but ...

@jreback You're right, that's definitely broken.

@jreback I'll put up a fix tomorrow. Sorry about that!

no...thank you for testing.....when I find something breaking...I realized that I didn't test it!

@jreback however, your example doesn't actually fail:

In [1]: from pandas import *
ind
In [2]: ind = Index(range(10))

In [3]: ind.name

In [4]: ind.rename('apple')
Out[4]: Int64Index([0, 1, 2, 3, 4, 5, 6, 7, 8, 9], dtype=int64)

In [5]: ind = _

In [6]: ind.name
Out[6]: 'apple'

The issue is that rename and name should only exist on Index (where they can only be used if you actually have an Index). Otherwise, you should use set_names and names. Not sure if there are other examples for "1d-ish" index vs. MultiIndex.

And it works for MultiIndex too...can you show what you mean by failing?

In [8]: import pandas as pd

In [9]: mi = pd.util.testing.makeCustomDataframe(5, 5).stack().index

In [10]: mi
Out[10]:
MultiIndex
[(u'R_l0_g0', u'C_l0_g0'), (u'R_l0_g0', u'C_l0_g1'), (u'R_l0_g0', u'C_l0_g2'), (u'R_l0_g0', u'C_l0_g3'), (u'R_l0_g0', u'C_l0_g4'), (u'R_l0_g1', u'C_l0_g0'), (u'R_l0_g1', u'C_l0_g1'), (u'R_l0_g1', u'C_l0_g2'), (u'R_l0_g1', u'C_l0_g3'), (u'R_l0_g1', u'C_l0_g4'), (u'R_l0_g2', u'C_l0_g0'), (u'R_l0_g2', u'C_l0_g1'), (u'R_l0_g2', u'C_l0_g2'), (u'R_l0_g2', u'C_l0_g3'), (u'R_l0_g2', u'C_l0_g4'), (u'R_l0_g3', u'C_l0_g0'), (u'R_l0_g3', u'C_l0_g1'), (u'R_l0_g3', u'C_l0_g2'), (u'R_l0_g3', u'C_l0_g3'), (u'R_l0_g3', u'C_l0_g4'), (u'R_l0_g4', u'C_l0_g0'), (u'R_l0_g4', u'C_l0_g1'), (u'R_l0_g4', u'C_l0_g2'), (u'R_l0_g4', u'C_l0_g3'), (u'R_l0_g4', u'C_l0_g4')]

In [11]: mi.set_names(["foo", "bar"])
Out[11]:
MultiIndex
[(u'R_l0_g0', u'C_l0_g0'), (u'R_l0_g0', u'C_l0_g1'), (u'R_l0_g0', u'C_l0_g2'), (u'R_l0_g0', u'C_l0_g3'), (u'R_l0_g0', u'C_l0_g4'), (u'R_l0_g1', u'C_l0_g0'), (u'R_l0_g1', u'C_l0_g1'), (u'R_l0_g1', u'C_l0_g2'), (u'R_l0_g1', u'C_l0_g3'), (u'R_l0_g1', u'C_l0_g4'), (u'R_l0_g2', u'C_l0_g0'), (u'R_l0_g2', u'C_l0_g1'), (u'R_l0_g2', u'C_l0_g2'), (u'R_l0_g2', u'C_l0_g3'), (u'R_l0_g2', u'C_l0_g4'), (u'R_l0_g3', u'C_l0_g0'), (u'R_l0_g3', u'C_l0_g1'), (u'R_l0_g3', u'C_l0_g2'), (u'R_l0_g3', u'C_l0_g3'), (u'R_l0_g3', u'C_l0_g4'), (u'R_l0_g4', u'C_l0_g0'), (u'R_l0_g4', u'C_l0_g1'), (u'R_l0_g4', u'C_l0_g2'), (u'R_l0_g4', u'C_l0_g3'), (u'R_l0_g4', u'C_l0_g4')]

In [12]: _.names
Out[12]: FrozenList([u'foo', u'bar'])

ahh...sorry...what I meant was that rename fails for multi-index (which is a nice name actually); I know it just calls set_names....but rename is cooler, that's why I was using it

These all should yield the same (I know I am abusing the input), but I am user of your functions!

In [1]: i = Index(np.arange(10))

In [2]: i.set_names(['foo'])
Out[2]: Int64Index([0, 1, 2, 3, 4, 5, 6, 7, 8, 9], dtype=int64)

In [3]: i.set_names(['foo']).name
Out[3]: 'foo'

In [4]: i.set_names('foo').name
ValueError: Length of new names must be 1, got 3

In [5]: i.rename('foo').name
Out[5]: 'foo'

In [6]: i.rename(['foo']).name
Out[6]: ['foo']

rename is just conviennce for set_names?

In [12]: mi.set_names(['foo','bar']).names
Out[12]: FrozenList([u'foo', u'bar'])

In [13]: mi.rename(['foo','bar']).names
ValueError: Length of names (1) must be same as level (2)

@jreback okay, well, trivial to enable rename for MultiIndex. I'm not sure I agree with your examples - especially because they lead to really strict type-sniffing.

rename is basically just lambda self, x: self.set_names([x])

@jtratner is rename different than set_names? (or is it supposed to be)?

R users are probably familiar with rename via the plyr package so I think we should keep it.

@jreback It would be for Index (since set_names always expects some kind of iterable).

@cpcloud heh, I introduced rename a few PRs ago so I'm not sure that it's compliant, would be good to check that though.

@cpcloud uh, I think you're thinking of dataframe/series here. Having a plyr-like rename would be kinda weird on Index.

yep ur right, carry on good sirs

Thing is the set_* makes sense for the MI, while rename for the name attributes, but set_names is a natural extension, ok...myabe just make them exactly the same then (with or with/out iterable is ok by me)

what is plyr rename do? (is it not the obvious thing?)....like (attach)??

@jreback ha! no....it's like DataFrame.rename. I got mixed up for a sec. You guys are talking about rename on Index objects, I was thinking about the frame version.

@cpcloud oh...that's not so obvious

here's what rename does

R > df <- data.frame(x=rnorm(10), y=rnorm(10))
R > df
            x          y
 1:  1.196889  0.8105994
 2: -0.185365 -0.7262135
 3: -0.613755  1.0857286
 4: -1.459379 -0.4459683
 5:  0.348874  0.3673212
 6:  0.401074 -0.0862284
 7:  0.398706  0.9814990
 8: -0.935906  0.7453723
 9:  0.243090  0.6259889
10: -0.428978 -0.8742873

R > rename(df, c(x="a", y="b"))
            a          b
 1:  1.196889  0.8105994
 2: -0.185365 -0.7262135
 3: -0.613755  1.0857286
 4: -1.459379 -0.4459683
 5:  0.348874  0.3673212
 6:  0.401074 -0.0862284
 7:  0.398706  0.9814990
 8: -0.935906  0.7453723
 9:  0.243090  0.6259889
10: -0.428978 -0.8742873

but that's OT

@jreback you can set names on index too:

ind.names = ['apple']
ind.name # 'apple'

I'd say the behavior that makes sense is something like:

• Index.rename : takes single object
• MultiIndex.set_names, Index.set_names - same type signature: take list of names [Index.set_names can only take iterable of length 1)
• MultiIndex.rename - synonym for set_names

So if you want to do something generically, you should use set_names (just like you would with other attributes). If you expect a non-MI index, then you could use rename with a string, etc.

@jreback well, I'll alias MultiIndex.rename to MultiIndex.set_names and add some test cases for rename, set_names, set_levels, and set_labels.

@jtratner that all looks good

@jreback to be clear - the only 'bug' with rename now is that MultiIndex should set rename to set_names, right?

I think that is right